‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Align env var with array semantics and allow multiple trusted origins (CSV).

better-auth expects an array for trustedOrigins. A single AUTH_TRUSTED_ORIGIN is limiting and semantically singular. Consider switching to a plural, comma-separated env to support multiple entries out of the box.

Apply this diff to the example:

-AUTH_TRUSTED_ORIGIN="start-ui-native://*" # Mobile app scheme for trustedOrigins config
+AUTH_TRUSTED_ORIGINS="start-ui-native://,start-ui-native://*" # Mobile app schemes for trustedOrigins config (CSV)

Follow-up:

• Keep backward compatibility by reading both AUTH_TRUSTED_ORIGINS (CSV) and legacy AUTH_TRUSTED_ORIGIN (single), if you adopt the change in the code.
• Ensure app/server/auth.tsx parses CSV when building the trustedOrigins array.

Run to locate all usages and assess impact (rename vs. dual support):

Additionally, verify whether better-auth accepts the wildcard form for custom schemes or if plain "scheme://" is sufficient:

🏁 Script executed:

#!/bin/bash
# Find occurrences of the old and proposed env names and trustedOrigins usage
rg -n -A2 -B2 $'AUTH_TRUSTED_ORIGIN\\b|AUTH_TRUSTED_ORIGINS\\b|trustedOrigins\\s*:'

Length of output: 756

🌐 Web query:

What formats does better-auth accept for the `trustedOrigins` option, and are custom URL schemes (e.g., start-ui-native:// or start-ui-native://*) supported?

💡 Result:

Better Auth accepts the following formats for the trustedOrigins option:

• An array of static origin strings (e.g., "https://example.com")
• A function that returns a list of origins dynamically
• Wildcard patterns (including domain wildcards and protocol wildcards)
• Custom URL schemes such as start-ui-native:// for deep links and mobile authentication flows[1][3][4].

Custom URL Schemes Support:

• Trusted origins can use custom schemes like start-ui-native:// to enable deep linking for mobile or desktop apps[3][4].
• You can list your custom scheme directly (e.g., "start-ui-native://").
• Wildcards with custom schemes are supported when you have varying paths or want to match all routes within the scheme (e.g., "start-ui-native://*")[3].
• This pattern is especially useful for Expo, React Native, and similar apps leveraging deep links after authentication[3].

Illustrative Example:

trustedOrigins: [
  "https://yourdomain.com",
  "start-ui-native://",
  "start-ui-native://*",
  "myapp-extension://*"
]

• "start-ui-native://" allows exact matches.
• "start-ui-native://*" matches any path or resource following the custom scheme, which is necessary if your app handles multiple deep-linked routes[3].

Key Details:

• Wildcards can be used after both standard protocols and custom schemes, but the scheme itself (e.g., start-ui-native) must match exactly—wildcarding does not change the protocol/scheme matching logic[4].
• For web origins, both domain and protocol wildcards are also supported (e.g., "https://*.example.com", "*.example.com"), with HTTPS preferred for security[4][1].
• Custom schemes are intended for apps and browser extensions; for browsers, redirection to custom schemes usually must be handled client-side for security reasons[8].

References:

• Full documentation: Better Auth config reference[1], security and trusted origins explanation[4], and Expo integration docs highlighting custom schemes and wildcards[3].
• Client-side handling for redirects with custom schemes: GitHub discussion[8].

In summary:
Better Auth’s trustedOrigins can accept static URLs, dynamic lists, wildcard patterns, and custom URL schemes (including wildcards such as start-ui-native://*). Custom URL schemes are a first-class feature for deep linking in mobile and desktop apps and should be explicitly listed in your configuration for safe origin handling[3][4].

Citations:

• 1: https://www.better-auth.com/docs/reference/options
• 2: https://www.better-auth.com/docs/concepts/database
• 3: https://www.better-auth.com/docs/integrations/expo
• 4: https://www.better-auth.com/docs/reference/security
• 5: https://www.better-auth.com
• 6: https://www.better-auth.com/docs/concepts/client
• 7: How to configure multiple domains? better-auth/better-auth#2296
• 8: google authentication w/ mcp plugin not triggering redirect to url better-auth/better-auth#3714
• 9: https://better-auth-ui.com/advanced/custom-settings
• 10: https://help.okta.com/en-us/content/topics/security/api-trusted-origins.htm

Provide a sane default and reduce friction in local dev.

AUTH_TRUSTED_ORIGIN is required with no default, while .env.example suggests "start-ui-native://*". Add a default to keep parity and avoid failures when the env is not set.

Apply this diff:

-    AUTH_TRUSTED_ORIGIN: z.string(),
+    AUTH_TRUSTED_ORIGIN: z.string().default('start-ui-native://*'),

Optional (future-proofing): if you decide to support multiple origins via CSV as suggested in .env.example, consider this alternative and adjust downstream code to expect an array:

// Optionally add alongside AUTH_TRUSTED_ORIGIN for backwards compatibility:
AUTH_TRUSTED_ORIGINS: z
  .string()
  .default('start-ui-native://,start-ui-native://*')
  .transform((v) =>
    v
      .split(',')
      .map((s) => s.trim())
      .filter(Boolean),
  ),

Confirm that app/server/auth.tsx actually consumes envServer.AUTH_TRUSTED_ORIGIN (or the proposed AUTH_TRUSTED_ORIGINS) when building the betterAuth trustedOrigins array, and that you’re not unintentionally hardcoding values:

🏁 Script executed:

#!/bin/bash
# Check usage of trustedOrigins and whether the env var is wired through
rg -n -A5 -B5 $'trustedOrigins\\s*:|AUTH_TRUSTED_ORIGIN\\b|AUTH_TRUSTED_ORIGINS\\b' app

Length of output: 1339